Dockerコンテナを使っているAWSサービスをブログ記事等とともに追いかけてみた
私の所属している部署（データアナリティクス事業本部)で開発するにあたってコンテナ周りを押さえておきたい・資格試験の勉強に向けてコンテナ周りを色々聞きたいと話が有り、そのときに話した内容をまとめてみました。
話をしたメンバーが話をしたあとに理解が進んだといった感想が嬉しかったのもあり、その時の内容をブログにまとめたいと思います。
コンテナって何？
この内容に関しては、元クラスメソッドで現在もゲストブロガーとして活躍している大瀧さんの記事を参考に解説しました。 今回話をしたメンバーはアプリ寄りのメンバーが多かったのもあり、以下の話をメインにコンテナの特徴を話しました。
開発環境が簡単に用意でき、かつ本番環境と共通化できる
Dockerには、コンテナーの元となるDockerイメージを異なるホスト間で共有する、「Docker Registry」「Docker Export／Import」という機能があります。 これらを利用することで、チーム開発において例えば開発用マシンで作成したイメージを他のメンバーのマシンに簡単にコピーできます。 さらにコピー先を本番マシンにすれば、アプリケーションのデプロイツールとして利用することも可能です。
コンテナーにはアプリケーションを実行するための構成が全てそろっているため、 かっこいい言い方をすればアプリケーションのポータビリティ（移植性）やインターオペラビリティ（相互運用性）を高める手段として活用できるともいえます。
アプリ開発者もインフラ管理者も知っておきたいDockerの基礎知識：いまさら聞けないDocker入門（1） - ＠IT
他にも kubernetes.io なぜコンテナなのか？ の記事等も参考に解説を行いました。 なぜコンテナなのか？の章は kubernetes というより、コンテナ技術の解説だったので、こちらも非常に分かり良かったです。
オーケストレーションツールって何？ どうして必要なの？？
いまやコンテナを使うにあたって切っても切れない話なのがオーケストレーションツールについての話になります。 ECSやKubernetes はコンテナのオーケストレーションサービスやオーケストレーションツールといった文脈で紹介されます。 オーケストレーションツールとは一体何でしょうか？
ここは以下のブログが非常にわかりやすくまとめられていました。
例えばコンテナ化したアプリケーションを何台ものサーバーへ展開するのは手間になり、複数のサーバーへ展開したコンテナがちゃんと稼働しているかどうかを監視することも必要になります。さらに万が一、いずれかのコンテナが落ちたときに別のコンテナを起動するクラスター管理、アプリケーションへの負荷が高まったらサーバーを増やし、負荷が減ればサーバーを減らすスケーラブルな運用対応や複数コンテナへのアクセスの分配など、さまざまな処理が必要となってきます。
こうした多数のコンテナに対する運用管理作業を一般に“コンテナオーケストレーション”と呼びます。そしてKubernetesをはじめとするコンテナオーケストレーションツールは、こうした作業を自動化してくれるのです。
コンテナオーケストレーションツールの“事実上の標準”という座をつかんだ「Kubernetes」。その重要性とは？ | 新野淳一コラム | 東京エレクトロンデバイス株式会社
また、この中でKubernetesはGoogleが開発を行い、オープンソース化されたオーケストレーションツールであるという話も行いました。
AWSでコンテナを用いるサービス群
上記まではコンテナやそれを取り巻く技術について話をしていったので、ここからはAWSに寄った話を進めていきます。 内部的にコンテナ技術を使っているサービス等もあるかもしれませんが、ここではDockerコンテナを明示的に使うサービスを対象としています。
| 年 | サービス |
|---|---|
| 2014 / 4 | Elastic Beanstalk Dockerコンテナサポート |
| 2014 / re:invent | Amazon Elastic Container Service(Amazon ECS) |
| 2015 / re:invent | Amazon Elastic Container Registry (ECR) |
| 2016 / re:invent | AWS Batch |
| 2016 / re:invent | AWS CodeBuild |
| 2017 / re:invent | AWS Fargate |
| 2017 / re:invent | Amazon Elastic Kubernetes Service (Amazon EKS) |
| 2019 / re:invent | Amazon Fargate for Amazon EKS |
さくっとこれらのサービスについて説明したいと思います。
Elastic Beanstalk
Elastic Beanstalkは開発したアプリケーションをデプロイ・スケーリングするサービスで、2014/4 UpdateでDocker対応されました。 先程紹介した大瀧さんの記事の解説を引用すると以下のようになります。
従来のElastic Beanstalkではあらかじめ決められたプログラミング言語やミドルウェアしかサポートされなかったのに対し、Dockerコンテナーであればそれらを自由に構成できるようになりました。 また、開発用マシンで作成したDockerイメージをAWSの本番環境でデプロイすることもできる、素晴らしい機能追加だと思います。
アプリ開発者もインフラ管理者も知っておきたいDockerの基礎知識：いまさら聞けないDocker入門（1） - ＠IT
Amazon Elastic Container Service(Amazon ECS)
2014年のre:invent で発表されたDocker コンテナのオーケストレーションサービスになります。 2014年に発表された際はAmazon EC2 Container Service といった名称だったようで、その名の通りDockerコンテナ扱うEC2を立ち上げ、その上でコンテナ郡の管理を行っていくサービスになります。
Amazon Elastic Container Registry (ECR)
Dockerのコンテナイメージを保管するサービスになります。 これを使うことでAWS内でDockerコンテナのイメージの保存、管理、デプロイすることが可能となりました。
ECRはDockerのRegistryをうまくAWSでラップしたサービスという印象です。
ECRにPushする際にAWS CLIの get-login コマンドを実行すると思うのですが、
実はこのコマンド中で実行されているコマンドを確認するとDocker Registry へのLoginを行っていることがわかります。
$ aws ecr get-login --no-include-email docker login -u AWS -p (パスワードのため省略) \ https://123456789012.dkr.ecr.ap-northeast-1.amazonaws.com
AWS Batch
フルマネージドのバッチサービスです。ジョブを定義をする際に、ジョブを処理する環境はDockerのコンテナイメージ上になります。 AWS Batchを動かしてみるとわかるのですが、前述のECSの上にバッチサービスを動かす仕組みをラップさせた仕組みという認識です。
AWS CodeBuild
フルマネージドのビルドサービスです。ビルド時に起動する環境がDockerのコンテナイメージとなります。 AWSが用意している環境を用いるのとは別に自前のビルド用Dockerコンテナを使うと言ったことも可能です。
AWS Fargate
コンテナを動かす際にコンテナのホストであるEC2を管理することなく、コンテナを起動させることができるサービスです。 ECSや後述するEKSを動かす際に用いることができ、用いることでコンテナホストであるEC2の管理が不要となります。
Amazon Elastic Kubernetes Service (Amazon EKS)
先程解説したオーケストレーションツールであるKubernetes をAWS上で扱うサービスになります。 既にKubernetesを用いた環境がある場合それらのマニフェストファイル等を用いることが可能となります。
【速報】AWSのマネージドKubernetesサービス、Elastic Container Service for Kubernetes(EKS)が発表されました！ #reinvent
Amazon Fargate for Amazon EKS
以下のブログから引用するのが一番良さそうです。
ECSにおいて、Fargateの登場によりコンテナインスタンス (EC2) の管理から解放されたように、 「Fargate for EKS」でも同様にEC2ワーカーノードの管理から解放されることが期待されます。
なんとなく「Fargate for EKS」が分かった気になる？ ～ いろいろなギモンを調べてみた ～ #reinvent
ECR ECS EKS関連を図示してみた
この話をしたときにしんやが図示してくれた図が非常に好評だったので清書してみました。
まとめ
このように歴史を追っていくことで、AWSがDockerを使ったサービスをどのように展開していったかがわかるかと思います。
まずBeanstalkでDockerを既存のサービスの中に組み込みました。次に、ECSでDockerコンテナのオーケストレーションサービスを作り、
ECRでコンテナを保存するRegistryをサービスとして提供してしました。その後CodeBuildやAWS Batchといった後Dockerコンテナを使うサービスを展開していったのだと思われます。
また、EC2の管理をなくしていくという形でFargateをリリースし、それと同時にオープンなオーケストレーションの仕組みであるKubernetesもAWS上で動かせるようにし、
最後に残っていたKubernetes上のEC2もFargateにしたと言った流れがわかるかと思います。
おまけ
この話をした際に、最後にメンバーから以下の質問がありました。
じゃあ実際に開発にあたってECSとEKSどっちを使うとよいの？
直接的な回答ではありませんが、以下のエントリを紹介しました。 自分としてもEKSのほうが難しそうって勝手な印象ではありましたが、 濱田の言葉を使うなら以下とのことです。
実際構築するときのコンテナ環境を作ったりCI/CDを整備するために必要な技術知識は、上の比較でも書いたとおりECSとEKSであんまり差が無い印象です。
